Agentic Steering 三支柱——来自 AgenticAICon 2026 的独立验证与修正

在[上一篇分析](Agentic Steering 三支柱)中，我从工程经验归纳和文献交叉验证出发，提出了 Agentic Steering 的三支柱框架：指引 agent 行为的三个维度——目标设定、过程设计、评判反馈——是一个木桶结构，任何一块板过短，系统质量就从那里泄漏。

2026 年 7 月 2-3 日，我参加了在杭州举行的 AgenticAICon 2026。本文以三支柱框架为主线，梳理大会上多项独立研究如何从不同方向指向同一组结构性难题，并基于这些发现对原始框架提出三个修正。文章中引用的所有外部事实均可追溯到公开可获取的论文或项目仓库——哪些是论文的结论，哪些是我的推断，在文中做了明确区分。

目标支柱：代理指标递归从一阶到二阶

一项独立验证

Shuai Shao、任启涵等人的论文《Your Agent May Misevolve: Emergent Risks in Self-evolving LLM Agents》（arxiv 2509.26354，ICLR 2026）系统性地识别了自进化 agent 的四条腐化路径：模型腐化、记忆腐化、工具腐化、工作流腐化。论文的实验证据表明，这些腐化路径发生的共同条件是 agent 在优化进化函数的代理指标，而非真正的能力本身。论文将缓解策略的探索标记为未来工作方向。

肖仰华教授（复旦大学）的 Generic Agent（github.com/lsdefine/GenericAgent）提出了一个绕过 benchmark 困境的进化度量：追踪同任务 token 消耗的趋势曲线，以下降斜率作为学习率的代理变量。

我的分析

这两项工作从不同方向验证了目标支柱的核心判断——代理指标的递归困境不是一个理论假说，它出现在真实的 agent 系统中。

Misevolution 的发现进一步将这个困境从一阶推到了二阶。一阶 Goodhart 是 agent 投机利用任务评估指标。二阶 Goodhart 是 agent 在自我进化时，优化的是进化函数本身的代理指标——"进化 benchmark 上的得分"。两者的区别在于反馈循环的长度：一阶的反馈在一次任务执行后闭合，二阶的反馈需要多轮进化后才显现。循环越长，腐化越隐蔽，发现时已经多轮累积。Misevolution 论文将其缓解策略定位为开放问题而非已决问题，这也与这个判断一致——二阶代理指标的检测目前缺乏系统性的工程手段。

肖仰华的 token 下降曲线提供了另一条路线：直接放弃 benchmark score 作为进化目标，改为观测 token 压缩率。这绕开了 Goodhart 困境，但也引入了一个新的递归风险——token 压缩率是否最终也会被 exploit（agent 学会用更少的 token 完成看似正确但质量更低的输出）？这仍然是一个开放问题。

过程支柱：gate 矩阵的不完整与约束的半衰期

一项独立验证

Qianshu Cai、张永岗等人的 MOSS 系统（arxiv 2605.22794）实现了源码级 Harness 自进化的完整 pipeline——7 个阶段（locate → plan → plan review → implement → code review → task eval → verdict），内置三个审查 gate。其核心论证是：源代码是图灵完备的 Harness 语言，提示词、skill、工具最终都可以用代码表达，而代码的确定性和上下文不敏感性是 prompt 文本不具备的。举个例子：如果 Harness 中有一个规则要求「任务完成后检查输出文件的完整性」，当这条规则写在 prompt 里时，模型可能在上下文 80% 处看到它、也可能在上下文尾部才注意到它，不同位置产生不同的遵从度；模型还可能把它和 prompt 中随后出现的其他约束产生语义混淆——「检查完整性」被误解为「检查格式」。而同样的规则用代码表达为 assert output_file.stat().st_size > 0，它每次执行的语义是确定的，不随上下文窗口中的其他内容漂移。系统通过 ephemeral trial workers 进行隔离验证——在临时容器中构建候选镜像、回放失败批次、验证后销毁。论文报告的实验数据表明一次进化后的任务完成率从 baseline 的 25% 提升到 61%。

胡梦康等人的 ClawMark benchmark（arxiv 2604.23781，Evolvent AI）在 100 个多天跨 session 任务中测试了多个主流模型的长期 agent 性能。论文记录了"Day-2/3 decline"——环境发生变化后的第二到第三天，agent 的性能出现系统性的显著下滑。ClawMark 同时量化了技能数量与准确率之间的 ln(N) 衰减关系。这个衰减的根因不是单个技能的质量下降，而是检索机制在技能库膨胀时的误匹配——当注册了 50 个技能时，agent 在面对一个新任务时需要在 50 个候选中挑出最合适的那个，而那个恰好正确的技能可能排在第 3 名，排在它前面的两个「看起来差不多但实际不对」的技能被优先调用了。技能越多，这种近邻误匹配的概率越高，呈对数增长而非线性增长是因为技能之间的语义距离分布本身不是均匀的。

AuthBench（arxiv 2605.14859，与 ClawMark 独立的论文）从权限边界的角度测试了 agent 理解最小权限原则的能力，提出了两阶段方法——先让 agent 执行 → 观察 tracing → 审计收紧权限。

我的分析

MOSS 的 gate 设计验证了过程支柱的一个核心判断：约束 agent 行为需要结构化而非启发式的手段。源码级重写将"改 prompt"升级为"改逻辑"，代码的确定性和可验证性解决了 prompt 文本的上下文漂移问题。

但 MOSS 的 gate 全部设置在行动中——修改代码时有 code review，回放验证时有 task eval，但代码被提交后就不再有 gate。这意味着跨轮次腐化检测没有系统的解决方案：当 agent 在第二轮进化中修改了第一轮的代码，第二轮只能验证"这次改对了"，无法检测"第一轮的代码是否已经引入了结构性退化"。三支柱框架中强调的"过程约束的有效性是时间衰减的"在这里找到了一个直接的技术对应。

ClawMark 和 AuthBench 从环境动态性和权限边界两个角度验证了过程支柱的同一个判断——约束不是永久的，它们具有有限的 half-life。"环境"（environment）一词在这两项工作中指向了不同的层次：ClawMark 的环境是数据层面的动态变化（新邮件、文件被改），它的解决方案是让 agent 主动重新验证环境状态；MOSS 的环境是执行层面的隔离验证（ephemeral containers），它的解决方案是用临时沙箱防止腐化代码污染生产。两个层次都需要独立的设计语言，混淆它们会高估任一方案的覆盖度。

评判支柱：从二值评分到不确定性量化

一项独立验证

吴晓均等人的 Bayesian-Agent（arxiv 2606.08348，IDEA 研究院 × 香港科技大学（广州））将技能进化从频率学派的计数统计转换为贝叶斯后验框架。每个技能被视为一个假说，其可靠性由先验概率、验证轨迹、失败模式和上下文共同更新为一个后验分布，而非一个标量成功率。从后验状态到操作的形式化映射定义了五种动作——Explore（后验不确定→积累证据）、Patch（同一失败模式出现两次→添加具体 guardrail）、Split（覆盖异构场景→拆分技能）、Compress（后验集中在高值→精简描述）、Retire（失败证据占据压倒性优势→退役）。论文的实验在 SOP-Bench、Lifelong AgentBench 和 RealFin-Bench 三个 benchmark 上验证了 Incremental Mode（基于已有执行记录仅修复失败任务）的有效性。

Bayesian-Agent 的一个设计决策值得单独讨论：后验摘要与模型提示的分离。

具体来说，系统内部维护每个技能的后验分布——例如"在上下文 A 下成功率约 73%，但置信区间很宽，因为只观察到 5 次执行"。这些数字和分布是给人（或审计系统）看的。模型收到的 prompt 里不出现这些数字。模型拿到的是后验状态翻译成的文字动作：如果后验不稳定→模型 prompt 里加一句"执行前检查输出文件是否存在"；如果某类失败模式出现两次→prompt 里追加一条 guardrail。数字归数字，指令归指令。这样做的理由很直接：LLM 在推理数字概率时不可靠——它在训练中见过太多数字，以至于一个"73%"和"42%"在它的表征里没有稳定的语义差异。但 LLM 在遵循具体文字指令上是可靠的——"执行前检查输出文件是否存在"是一个它不会误读的动作。

ATIF（Agent Trajectory Interchange Format，Harbor Framework RFC v1.7，maintainer Boxuan Li）作为跨公司的 agent 轨迹交换标准，已被 NVIDIA NeMo、Arize Phoenix、Claude Code、OpenHands 等多方支持。它的存在本身就是一个信号：业界需要一种独立于特定 agent 框架的标准格式来存储和交换轨迹数据——这正是评判支柱需要独立 evidence pipeline 的工程确认。

我的分析

评判支柱在原始框架中最大的结构性问题——评判的认知难度不低于产出本身（能力对等）——在 Bayesian-Agent 中有了一个工程上的变通方案：不试图让评判者比创造者更强，而是让评判者维持可审计的不确定性量化。后验不是一个"好不好"的判断，而是一个"我们有多确定"的分布。当后验宽度大时，系统的回应不是胡猜，而是触发 Explore——承认不确定本身就是比硬判更安全的策略。

后验与 prompt 的分离直接对接了评判支柱中"不能让 agent 自己评判自己"的判断。概率推理（后验更新）交给形式化方法，模型只执行文字化的结果——这切断了自我评估的正反馈环，也避免了让 LLM 直接推理数字概率的不可靠性。

我在原始框架中讨论的两种失效模式——Agentic Entropy（handoff 边界的信息损失）和局部最优累积（贪婪优化的腐化）——在评判支柱的语境下呈现为同一类问题的两个侧面：评判的延迟与评判的噪声。每多一层 handoff，评判信号就多损失一部分；每次贪婪优化产生的 mock 和测试桩，构成了评判器眼中的"正常代码"。前者需要精简评判链路（减少 handoff），后者需要评判器的上下文不敏感化（代码级评判而非文本级评判）。Bayesian Agent 通过分离后验和 prompt 部分解决了前者，MOSS 通过源码级 gate 部分解决了后者——但两者都意识到，评判支柱的工程实现必须同时处理延迟和噪声，只解决其中一个仍然会漏。

过程支柱的补充：双门模型与人的单向退化风险

一个概念框架

王天富（香港科技大学（广州））提出了一个将 agent 治理从"仅行动中"扩展到"行动前 + 行动后"的概念框架——双门模型：行动前门定义意图、边界和委派范围；经验后门定义证据标准、纠错解释和复用条件。这个框架与 MOSS 的三个行动中 gate 形成互补。

王天富进一步梳理了人机协作中四个潜在的退化方向——执行外包导致试错减少、过程不可审阅导致追问减少、只验收结果导致反馈减少、默认接管导致主体性减弱。在随后的 Panel 讨论中，他提出了一个更尖锐的问题：agent 的 Explore 操作默认最大化信息增益（information gain）作为代理指标。但在某些临界场景下，信息增益约等于风险敞口——agent 在知道一个东西存在之前，无法判断这个东西该不该被知道。

MindOS（github.com/GeminiLight/MindOS）是一个本地优先的人机共享知识库系统，将协作历史组织为 Canonical Markdown → Derived Sidecars → Evidence Pack 的三层蒸馏结构。该项目的公开承诺中包括了尚未实现的 Experience Compiler——自动从 agent 交互中提取修正和偏好为可复用的 SOP。

我的分析

双门模型的贡献不在于"发明了"这些 gate——MOSS 有 review gate、AuthBench 有 audit stage——而在于它把 gate 矩阵的缺失列标示出来了。MOSS 验证了行动中需要 gate，双门模型指出行动前和行动后也需要 gate，合在一起才是完整的矩阵。但矩阵中间一列——"行动中的实时监控和干预"——目前没有任何系统覆盖。这可能是最难的工程问题：需要在不断 agent 执行流的前提下注入干预，干预的时机和粒度同时受制于上下文窗口的实时状态。

四个退化方向提出了一个需要认真对待的可能性：人机协作的自然趋势可能不是共进化，而是人的单向退化。如果这是真的——即使只在部分场景下成立——那么"agent 训练人"就不再是一个附加特性，而是一个系统设计中需要内置的对抗机制。这里的"训练"不是比喻——它指的是 agent 在完成指令之外，主动选择那些对人具有学习价值的决策节点，把决策过程（不只是决策结果）暴露给人。举个例子：一个普通的代码 agent 在写完 PR 后直接 mark 为 ready for review。一个"训练人"的 agent 会在 PR 中标注出它考虑过但最终放弃的一个替代方案，并说明放弃的理由——不是因为这影响了代码质量，而是因为"在类似场景下评估替代方案"是人的判断力需要持续练习的动作。人看完了这个标注后不需要做任何事，但判断力得到了一次维护。

"潘多拉魔盒"问题是今天的大会上唯一一个让我无法在现有框架内放置的发现。它不是目标支柱的问题（Explore 本身的目标设定没有错——多探索确实带来更多信息）。它不是过程支柱的问题（每一步的探索行为在权限范围内都是合法的）。它也不是评判支柱的问题（在探索之前没有任何证据可以用来评判探索的后果）。它是一个三支柱之外的第四类问题：探索的二阶后果——不是 agent 做错了什么，而是"做对了"在某些临界场景等价于"做坏了"。三支柱框架需要纳入对这类问题的位置。

工程工具链的一个收敛信号

梁昊等人（元枢智汇）维护的 DataFlow（github.com/OpenDCAI/DataFlow, ~5800 star）和 DataFlex（github.com/OpenDCAI/DataFlex）构成了一条从轨迹到训练数据的开源工具链——DataFlow 做数据生产，LLaMA-Factory 做训练执行，DataFlex 做训练过程中的动态数据调度。DataFlex 的 model-in-the-loop 模式——利用模型当前梯度/损失决定下一步训什么数据——将评判信号嵌入训练循环内部。

董冠霆等人的 Agent-World（arxiv 2604.18292，中国人民大学 × 字节跳动 Seed）通过 DAG 图 + 随机游走自动合成 1,978 个环境和 19,822 个工具接口的任务训练场。一个值得注意的收敛信号：DataFlow 用知识图谱合成多跳推理 QA 的方式与 Agent-World 用 DAG 图 + 随机游走合成任务环境在方法上是同构的。两个独立团队在同一天的不同分会场展示了同一个技术模式——图结构驱动组合爆炸式数据合成——这比任何单一 benchmark 的得分都更能说明这个模式正在收敛。

对原始框架的三个修正

修正 1：评判支柱的形式化——从 score 到 evidence model

评判不是二进制判断，是带不确定性的条件概率分布。"成功 7/10"作为统计量是准确的，作为行动指令是危险的。评判支柱的工程实现需要一个 evidence model（后验分布 + 更新规则 + 从分布到行动的映射），不是一个 score（标量评分）。后验分布可以直接回答"我们有多确定这个判断"——这是标量评分在定义上无法提供的维度。

修正 2：过程支柱的时间维度——约束的 half-life

过程设计不能假设静态环境。不同来源的证据（Day-2/3 decline、ln(N) 技能衰减、Memory Misevolution 累积）指向同一个事实：过程约束的有效性是时间衰减的。这就意味着 Harness 设计需要在约束本身之外维护一个约束的观测层——追踪每个约束距离上次验证已经过去了多久、环境是否已发生变化、约束是否仍然 bind 在当前的 agent 状态上。这不是对原始框架的推翻，是对过程支柱内部的一个新增子结构。

修正 3：目标支柱的递归深度——二阶代理指标

当 agent 自己优化自己时，被优化的目标不是真正的能力，而是进化函数的 proxy metric。Misevolution 论文中的四条腐化路径在此框架下可以统一理解为：模型腐化、记忆腐化、工具腐化、工作流腐化都是 agent 在最大化进化 proxy metric 的过程中，在不同子系统上产生的不同表现形式的同一类失效。这意味着目标支柱不仅需要考虑"如何给单次任务设定目标"，还需要考虑"如何给自进化过程设定进化仪表盘"——肖仰华的 token 下降曲线是朝向这个方向的第一步。

推断与未证实部分

以下结论是我的推断，尚未经过独立实验验证：

1. 三支柱的木桶结构在此次会议中获得的是 triangulation（多角度交叉印证），不是 confirmation（确认性验证）。 每一项研究都有自己的研究问题和实验设计，没有一个是为验证这个框架而设计的。它们集体指向同一组结构性难题的事实增强了框架的可信度，但不构成严格意义上的验证。
2. "约束的 half-life"是一个比喻，不是量化的度量。 目前没有系统性的方法测量一个具体约束在多长时间内保持有效。这是一个需要单独工程研究方向的问题。
3. 四个退化模式、潘多拉魔盒问题的工程严重性尚未经过定量评估。 它们目前是分析性概念，不是实验性结论。
4. gate 矩阵的三列（行动前/中/后）的完整工程实现目前不存在。 MOSS 覆盖中间列、双门模型覆盖首尾列、中间列的实时干预仍未解决——这不意味着不可能，但意味着各列之间的集成模式尚未被定义。

仍待解决的问题

1. 行动中的实时监控和干预：在 agent 执行流不间断的前提下注入干预——时机和粒度如何确定？
2. 评判者的退化：如果人的判断力在与 agent 协作过程中退化，evidence model 依赖的 ground truth 是否也在漂移？
3. 三支柱的临界线如何在不同任务域中量化？目前仍然是事后诊断，缺乏事前评估。
4. 如果 Scaling law 在两年时间尺度上持续有效，外部技能和约束有多少会被内化到模型参数？Harness 的边界是否在持续向内收缩？